Thank you for reviewing!

README: modify the documentation badge

I think the documentation badge in README seems fine, should we add badge for main pipeline. Or did I misunderstand your change request?

If the pipeline is run on master branch (post PR merge), what will the diff stage do? Will it skip the pipeline?

It's certainly a problem for running on master.I tested direct push using git diff HEAD HEAD~1 and it was modified for PR check without much concern:sweat_smile:, sorry for that. So I think adding a check for master branch or PR merge in script and use git diff HEAD HEAD~1 for direct push will address this issue.

So far looks good to me. What's the plan here @ueqri ?

Sorry for replying so late.

I think this enhancement is ready for further developments, e.g. enabling CUDA build on CI(GSoC 2021 Project), integrating clang-tidy and sanitizers for CI(#4629), separating build and test as different stages(#3947), etc.

And I plan to add a documentation as descriptions about CI structure in .ci folder. Then could we merge this PR and test the new pipelines in this drafted PR #4715?

Sounds good to me. Could you clean up the code, add comments, etc. if needed and ping again (or asap if not needed) for the review?

Sounds good to me. Could you clean up the code, add comments, etc. if needed and ping again (or asap if not needed) for the review?

Thanks for your kind help! I would do it soon. 😀

I think it's ready for 🚀 . And we could update the structure.md for detailed explanations whenever there are some features introduced to CI in the future. 😆

Regarding the svg image, thoughts on using something like PlantUML? Sample code + image here

Thank you for your kind review!

Could we have a single git diff stage and set the variables there?

In the latest commit, two git diff stages are separated to two pipelines(main & docs pipelines).

But sharing variables across pipelines in Azure isn't well implemented according to the official documents. If we want to do this, we need a variable groups which can't be created in YAML. Reference.

So could we just keep the duplicate until we find a better way to address the issue?

What's the benefit of using pipeline trigger compared to just having them as different stages, included from a separate file? (Since GCC -> generate doc + tutorials is 100% assured)

Although introducing another pipelines may be not a good choice for Azure Ops, pipeline trigger is much smoother to maintain the CI than the flow-control methods for stages or jobs.

The stages are mostly supposed to run sequentially (run only once, only after certain stage completes), depending on the position or specific parameter in YAML. So the control of docs stages (without pipeline trigger) will be quite tough. The detailed discussion is as follows.

The trigger for docs stages are only for two reasons:

• Only documentations change
• Build GCC stage completes successfully (implying it has codes changed)

Here are some relevant solutions:

• If we use dependsOn: build_gcc or dependsOn: OnlyDocsChangeDiff for docs stage, the stage will be skipped if no codes changed or no docs change, respectively.
• If we use conditions to control docs stage in YAML, we would add 1) OnlyDocsChangeDiff false => build_gcc OK => docs stage; 2) OnlyDocsChangeDiff true => docs stage. And use OR(... , ...) to combine them. Then if we use dependsOn: [ ] to avoid sequential running, what concerns me is the undefined behavior that a parallel stage fetch the status of others. If we put the docs stage after build_gcc without using parallel, the docs will skip together with build_gcc.

Therefore, I think pipeline trigger is a better tool to carry these complex flow-control tasks.

Regarding the svg image, thoughts on using something like PlantUML? Sample code + image here

Thanks for your advice! 😀 I'd like to try the UML form, which is more logic, although the previous Draw.io is easy to create and drag.

Thanks, your reasoning is quite solid. The PR looks good to me except the image (text preferred)